NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/3272

Internet Message Format | 1996-08-05 | 4.7 KB

Path: Rezonet.net!news
From: [e-mail] (Ray Dunn)
Newsgroups: comp.lang.c
Subject: Another good reason for using static
Date: 25 Jan 1996 02:22:57 GMT
Organization: Ultimate Technographics Inc.
Message-ID: <4e6pi1$[e-mail]>
NNTP-Posting-Host: 204.19.230.7
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
X-Newsreader: WinVN 0.99.7

Although this is not strictly a language issue, but a linker issue,
it appears to not be system specific, so I hope the topic is relevant
here.

After the recent thread on the proper use of static and extern, I
received email from someone who alluded to something I hadn't paid
serious attention to before (sorry, there was a server crash which
lost the mail before I could reply).

Programmers of multi-module programs must be aware of *linkage*
issues, as well as *scope* issues, because identifiers declared
in different scopes can be made to refer to the same identifier at
link time.

If two modules of a program declare the same variable, say "int x;"
with file scope, and don't declare at least one of them as "static",
then in most systems I know, these identifiers have external linkage,
i.e. the linker will usually resolve "x" to the same address in both
modules, even though neither module uses the extern storage-class
specifier.  This is exactly the same mechanism that causes the linker
to complain of a multiple definition of a function if you use the
same function name in two modules and don't declare at least one as
"static", but in the case of non-function identifiers, the linker
doesn't consider it a multiple definition.

Most linkers don't carry type information along with the identifiers
they are trying to resolve, only their names, so that even if one
module declares "int x;" and the other module declares "long x;", the
linker is not aware of any difference, and still resolves both x's to
the same address, with obvious catastophic results.

This can, and should, be overcome in most programs by the discipline
of declaring all relevant identifiers as static, so they have
internal linkage, and using an extern declaration in a header file
for all identifiers required to have external linkage, to ensure that
all modules use the identifiers consistently.

There are situations, though, where it would seem to be quite
difficult to ensure that these problems are detected.

I'm currently working on a large program which consists of two very
separate pieces of functionality.  There is a front-end (the user
interface) and a back-end (the processing engine).  Each of these
consists of many program modules, which are essentially independant
of all the modules in the other set, and there is a set of bridge
modules, which contain references to functions and variables on each
side.

All of the module objects are linked together, the front-end, the
bridge, and the back-end, so that the linker is globally trying to
resolve all identifiers with external-linkage at the same time.

Here's the problem.

The back-end code is written by a separate group, is known to be
"global heavy", haphazard in its use of include files,  and the
development is outside my control (Real-Life-Management (tm)). If the
writers of that module have chosen any identifiers with the same
names as any externs I'm using, I'm in trouble, and although I can't
be responsible for the product as a whole, I would like to minimize
problems under my control!

If the back-end was written by a group who, for the usual commercial
reasons did not want to publish their sources, this would be much
more serious.  Fortunately, in this case, I do have access to the
sources, and always recompile them including the header files of the
front-end and bridge modules, which consistently declare all
externally linked identifiers.  This allows me to detect if the
back-end is using any of the front-end names but with different
types, but it still doesn't detect if the back-end is using the same
identifiers but for different purposes that would cause interference
with the front-end.

The problem is minimized by the use of hopefully unique names in the
front-end, and I'm currently attempting to totally resolve the
problem by isolating the back-end into a DLL, but there are bridging
issues.

Although I'm stuck with a specific development environment, does
anyone know of *any* system that would allow a "fire-wall" to be
erected between these two modules, given that the bridge between them
must also exist, or of any linker that ensures uniqueness between
identifers in different scopes even if not declared static?
--
Ray Dunn (opinions are my own) | Phone: [phone]
Montreal                       | Phax : [phone]
[e-mail]          | Home : [phone]